Skip to content

Conversation

@SwayamInSync
Copy link
Member

@SwayamInSync SwayamInSync commented Dec 6, 2025

closes #239

Saturday spend well! Some points to mention:

  • String parsing helpers inside utilities.c and their corresponding calls have been modified because of the modified behaviour of Sleef_strtoq and handling of negative NaN.
  • extra dependency of tlfloat
  • revision is set to the latest commit upto the date of this PR (43a0252), not setting to master as maybe in future more routine behaviour changes can break the dtype here (Ideally in future it'll be better to migrate the core changes from master if something fundamental breaks)
  • SSE Instructions are by default disabled in this new version (maybe maintainig them is cost effective) QBLAS still uses them, I'll update them there and then we can maybe update here or keep it as it is
  • Added more tests that replicate the bug from the mentioned issue, and similar pattern for other binary ops

Copy link
Contributor

@juntyr juntyr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@SwayamInSync
Copy link
Member Author

Took the opportunity to also clean the building process and warnings

@SwayamInSync SwayamInSync added this to the v1.0 milestone Dec 8, 2025
Copy link
Member

@ngoldbaum ngoldbaum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's unfortunate the parsing code had to change so much. It might be a little clearer if you do a first PR that does some refactoring in the parsing code, then rebased this PR on top of that one. Up to you if you feel like it's worth it.

I see you replaced cstring_to_quad with NumPyOS_ascii_strtoq - do we ever want to user the former anymore? If so, when? Maybe worth adding as a comment somewhere.


// Call Sleef_strtoq with the bounded string
char *sleef_endptr;
out_value->sleef_value = Sleef_strtoq(temp, &sleef_endptr);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is pretty subuptimal :(

Consider refactoring all the code you added here into a function even if there's only one caller, since it's pretty distracting here inline in this function.


@pytest.mark.parametrize("invalid_bytes", [
b"1.0 ", # Trailing whitespace
b"1.0 ", # Multiple trailing spaces
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why delete test cases? it seems like the parsing code changed a lot above, if anything I'd expect added test cases here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because even if for scalars, numpy and python handle the trailing whitespace correctly and parse the input
and here these are the tests that tests the invalid inputs (meant to be failed)

@SwayamInSync
Copy link
Member Author

kinda seems like a SLEEF bug you should report

Reported it here shibatch/sleef#706

@SwayamInSync
Copy link
Member Author

hint: You require CPython 3.11 (cp311), but we only found wheels for
numpy (v2.5.0.dev0) with the following Python implementation tags:
cp312, cp313, cp314

It seems on conda nightly for numpy-2.5 does not have py-11 wheels. Since it's just for typecheck workflow I think for simple use I can just bump the python requirement there instead of setting to build from repo

@SwayamInSync
Copy link
Member Author

So tl;dr I refactored the string parsing logic and now every call site is using NumPyOS_ascii_strtoq (which first parses the input, handling inf/nan, leading whitespaces) and then if the quantitty is still parsable then delegates to internal helper cstring_to_quad_internal (this is not exposed and it just convert the remaining entity to the quad)

SLEEF 4.0's strtoq's all limitations are handled by this internal helper so in future if they fix those we just need to update this internal helper, the exposed public API will remain the same

cc: @ngoldbaum I hope you like this setup

def __add__(self, other: _IntoQuad, /) -> Self: ... # type: ignore[override] # pyright: ignore[reportIncompatibleMethodOverride]
@override
def __radd__(self, other: _IntoQuad, /) -> Self: ... # type: ignore[override] # pyright: ignore[reportIncompatibleMethodOverride]
def __radd__(self, other: _IntoQuad, /) -> Self: ... # type: ignore[override, misc] # pyright: ignore[reportIncompatibleMethodOverride]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nothing wrong with this, so I agree that mypy should shut up here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 + x = x/2

4 participants